Skip to content

Conversation

mukunku
Copy link
Contributor

@mukunku mukunku commented Oct 5, 2025

Summary

This PR proposes the idea of exposing an IProgress<int>parameter in the SaveAsAsync() extension methods.

Reason

I provide file export options in my WinForms utility and for all other supported file types I am able to show a progress bar (since I know the total number of cells to be exported beforehand) but cannot do this with .xlsx files currently.

Remarks

I really like that this library streams the data as it writes it instead of buffering it in memory so thanks to the creator and supporters.

Copy link
Contributor

Summary of Changes

Hello @mukunku, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the MiniExcel library by integrating a progress reporting mechanism into its file export capabilities. By exposing an IProgress<int> parameter in key asynchronous export methods, users can now monitor the progress of their Excel and CSV file generation. This improvement is particularly beneficial for applications dealing with large datasets, as it allows for a more responsive user interface and better user experience during potentially long-running export operations.

Highlights

  • Progress Reporting for Exports: Introduced an IProgress<int> parameter to SaveAsAsync and ExportAsync methods across Excel (XLSX) and CSV export functionalities, allowing real-time progress tracking during file generation.
  • API Extension: The IProgress<int> parameter has been added to the IMiniExcelWriter interface, OpenXmlExporter, CsvExporter, and the main MiniExcel static SaveAsAsync methods.
  • Granular Progress Updates: Progress is reported for each cell written during the export process in both OpenXML and CSV writers, providing detailed feedback on the export operation's advancement.
  • New Test Cases: Dedicated unit tests have been added for both Excel and CSV exports to validate the correct functioning and reporting of the IProgress<int> implementation.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a great feature to report progress during export operations by exposing an IProgress<int> parameter. The changes are well-implemented across the different exporters (XLSX and CSV) and public APIs. The new functionality is also covered by unit tests, which is excellent. I've found a couple of issues in the method calls that I've commented on. Once those are addressed, this will be a solid addition to the library.

@michelebastione
Copy link
Contributor

@mukunku Thank you for your contribution, I'll review it soon!

@michelebastione
Copy link
Contributor

@mukunku I think it would be generally more useful to signal progress after every row is processed rather than after every cell, and it would also save a lot on overhead. what do you think?

@mukunku
Copy link
Contributor Author

mukunku commented Oct 12, 2025

@mukunku I think it would be generally more useful to signal progress after every row is processed rather than after every cell, and it would also save a lot on overhead. what do you think?

I think it makes more sense to let the caller decide the granularity. Performance would be entirely dependent on how the caller is handling progress reports and if someone wants row based progress they can do that themselves: if (progress % columnCount == 0) { /*do stuff*/ } .

Doing it cell based doesn't have any performance impact in and of itself. I.e. Reducing method calls in a loop isn't going to have any noticeable impact in real-world use-cases: https://stackoverflow.com/a/8418119 . As mentioned in that answer your for-loop would need to do trillions of iterations for you to even start noticing an impact considering how fast modern processors are.

I tried to see what others have written on this topic in the past and I found this which seems to suggest the same thing: https://stackoverflow.com/q/19661194

Ultimately i dont think there's a right answer but i prefer the cell based reporting as it offers the most flexibility with no, imo, downsides.

@michelebastione
Copy link
Contributor

Alright, I'm still not convinced that would end up being very useful but ultimately it shouldn't really matter very much, and it's gonna be easy to revert in case we change our mind in the future. I'll make a few tweaks and merge it in the next couple of days.

- Added IProgress parameter to OpenXmlExporter.InsertSheet and CsvExporter.Append methods
- Reworked parameters order in the changed methods
- Moved new tests to OpenXmlAsyncTests and CsvAsyncTests classes and removed new superfluous files
@michelebastione michelebastione merged commit 2443e75 into mini-software:master Oct 13, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants